1. Field of the Invention
The invention relates generally to management of logical volumes in a storage system, and more specifically relates to techniques for hiding the existence of storage devices and/or logical volumes to portions of a storage controller and/or host systems under certain circumstances.
2. Related Patents
This patent is related to the following commonly owned United States patent applications, all filled on the same date herewith, and all of which are herein incorporated by reference:
U.S. patent application Ser. No. 13/432,131, entitled METHODS AND STRUCTURE FOR TASK MANAGEMENT IN STORAGE CONTROLLERS OF A CLUSTERED STORAGE SYSTEM;
U.S. patent application Ser. No. 13/432,213, entitled METHODS AND STRUCTURE FOR DIRECT PASS THROUGH OF SHIPPED REQUESTS IN FAST PATH CIRCUITS OF A STORAGE CONTROLLER IN A CLUSTERED STORAGE SYSTEM;
U.S. patent application Ser. No. 13/432,223, entitled METHODS AND STRUCTURE FOR LOAD BALANCING OF BACKGROUND TASKS BETWEEN STORAGE CONTROLLERS IN A CLUSTERED STORAGE ENVIRONMENT;
U.S. patent application Ser. No. 13/432,225, entitled METHODS AND STRUCTURE FOR TRANSFERRING OWNERSHIP OF A LOGICAL VOLUME BY TRANSFER OF NATIVE-FORMAT METADATA IN A CLUSTERED STORAGE ENVIRONMENT;
U.S. patent application Ser. No. 13/432,232, entitled METHODS AND STRUCTURE FOR IMPLEMENTING LOGICAL DEVICE CONSISTENCY IN A CLUSTERED STORAGE SYSTEM;
U.S. patent application Ser. No. 13/432,238, entitled METHODS AND STRUCTURE FOR IMPROVED I/O SHIPPING IN A CLUSTERED STORAGE SYSTEM;
U.S. patent application Ser. No. 13/432,150, entitled METHODS AND STRUCTURE FOR IMPROVED BUFFER ALLOCATION IN A STORAGE CONTROLLER; and
U.S. patent application Ser. No. 13/432,138, entitled METHODS AND STRUCTURE FOR RESUMING BACKGROUND TASKS IN A CLUSTERED STORAGE ENVIRONMENT.
3. Discussion of Related Art
In the field of data storage, customers demand highly resilient data storage systems that also exhibit fast error recovery times. One type of storage system used to provide both of these characteristics is known as a clustered storage system.
A clustered storage system typically comprises a number of storage controllers, where each storage controller processes host Input/Output (I/O) requests directed to one or more logical volumes. The logical volumes reside on portions of one or more storage devices (e.g., hard disks) coupled with the storage controllers. Often, the logical volumes are configured as Redundant Array of Independent Disks (RAID) volumes in order to ensure an enhanced level of data integrity and/or performance.
A notable feature of clustered storage environments is that the storage controllers are capable of coordinating processing of host requests (e.g., by shipping I/O processing between each other) in order to enhance the performance of the storage environment. This includes intentionally transferring ownership of a logical volume from one storage controller to another. For example, a first storage controller may detect that it is currently undergoing a heavy processing load, and may assign ownership of a given logical volume to a second storage controller that has a smaller processing burden in order to increase the overall speed of the clustered storage system in handling I/O requests. Other storage controllers may then update information identifying which storage controller presently owns each logical volume. Thus, when an I/O request is received at a storage controller that does not own the logical volume identified in the request, the storage controller may “ship” the request to the storage controller that presently owns the identified logical volume.
FIG. 1 is a block diagram illustrating an example of a prior art clustered storage system 150. Clustered storage system 150 is indicated by the dashed box, and includes storage controllers 120, switched fabric 130, and logical volumes 140. Note that a “clustered storage system” (as used herein) does not necessarily include host systems and associated functionality (e.g., hosts, application-layer services, operating systems, clustered computing nodes, etc.). However, storage controllers 120 and hosts 110 may be tightly integrated physically. For example, storage controllers 120 may comprise Host Bus Adapters (HBA's) coupled with a corresponding host 110 through a peripheral bus structure of host 110. According to FIG. 1, hosts 110 provide I/O requests to storage controllers 120 of clustered storage system 150. Storage controllers 120 are coupled via switched fabric 130 (e.g., a Serial Attached SCSI (SAS) fabric or any other suitable communication medium and protocol) for communication with each other and with a number of storage devices 142 on which logical volumes 140 are stored.
FIG. 2 is a block diagram illustrating another example of a prior art clustered storage system 250. In this example, clustered storage system 250 processes I/O requests from hosts 210 received via switched fabric 230. Storage controllers 220 are coupled for communication with storage devices 242 via switched fabric 235, which may be integral with or distinct from switched fabric 230. Storage devices 242 implement logical volumes 240. Many other configurations of hosts, storage controllers, switched fabric, and logical volumes are possible for clustered storage systems as a matter of design choice. Further, in many high reliability storage systems, all the depicted couplings may be duplicated for redundancy. Additionally, the interconnect fabrics may also be duplicated for redundancy.
While clustered storage systems provide a number of performance benefits over more traditional storage systems described above, system administrators still desire the flexibility in controlling the visibility of storage devices and logical volumes in clustered storage to avoid confusion and human error in accessing non-authorized resources. One possibility of controlling the visibility of storage devices and logical volumes in a SAS fabric is through the use of SAS zoning. SAS zoning utilizes zoning expanders to limit the resources that each host “sees” by configuring different policies for each SAS zone within the SAS fabric. In SAS zoning, expander PHYs are assigned to groups to allow access policies to be configured for the different groups. The access policies can ensure that only authorized users can access or “see” certain part of the system. From the perspective of a SAS system administrator, SAS zoning requires no change to the end devices in the network. Initiators continue to perform normal SAS discovery, and initiators and targets send and receive open address frames as usual. However, unlike a typical SAS fabric, initiators and targets do not see the entire SAS domain, also known as a service delivery subsystem. Instead, they only see the portions of the domain, otherwise known as groups, that they have been given permission to see based on a permission table that is configured for and stored at each zoning expander.
While SAS zoning allows for controlling the visibility of storage devices and logical volumes within the SAS fabric, problems may arise when communication failures occur within a zoning topology. For example, if an HBA “owns” a zoning permission table stored at a zoning expander and the HBA becomes unavailable, then it may be difficult to re-assign ownership of the permission table to a new HBA. This leads to failover recovery issues when network problems arise in SAS fabrics that implement SAS zoning. Furthermore, in multipath (i.e., redundant) topologies, wherein an HBA may be coupled with multiple expanders, a similar problem is encountered in that the HBA may be required to re-zone each of the multiple expanders in order to effect a zoning change. If a failure is encountered in a connection between the HBA and one of the expanders, the HBA may be unable to properly implement the zoning change at all of the expanders. Thus, other HBAs in the multipath topology may be exposed to inconsistent zoning information at the different expanders, which is problematic.
Thus it is an ongoing challenge to control the visibility of storage devices and logical volumes in a clustered storage environment.